The Simple Network Management Protocol (SNMP) is a protocol enabling the control and management of devices communicating over a network. The network devices may be controlled by SNMP commands sent from a network management station (NMS) to an SNMP agent for the network device. One or more Management Information Bases (MIBs) loaded on the network management station are used to determine which commands to send to the SNMP agent. A MIB specifies management information and events for a device in a defined format and includes both prose descriptions and computer-readable descriptions. The SNMP agent accepts properly formatted communications from the network management station and allows the remote configuration of the device from the network management station.
There are several reasons why a network administrator may want to contact an SNMP agent in a live network. For example, one reason may be to retrieve diagnostic values on an SNMP agent or device implementing an SNMP agent. Using a sufficiently knowledgeable NMS (one that has loaded both standard MIBs and very often vendor proprietary MIBs), the SNMP agent can be queried by the NMS by sending an SNMP packet which includes specific Object Identifiers (OIDs). These OIDs represent objects that the network administrator is interested in, such as CPU Utilization, Bytes (coming into or out of a network interface on a device), Memory Utilization, and objects holding other device information. Another reason would be to modify values on an SNMP agent to configure it to support a new mode of operation or cause the device to behave in a certain way.
Unfortunately, the MIBs (one or more) needed to control the SNMP agent for the device communicating over the network, and thus the device, vary depending upon the vendor of the device. Conventional methods of determining, retrieving and updating MIBs needed to control an SNMP agent for a network device all suffer from various drawbacks. One conventional method of determining the MIBs needed to control the SNMP agent involves the querying of a vendor specific region of a separate MIB for the SNMP agent. As the SNMP agent hosted MIB is proprietary, this requires a different procedure for each vendor. Another method of determining which MIBs are necessary to communicate with the SNMP agent is to query a table defined in the SNMPv2-MIB specification called sysORTable and implemented on the SNMP agent MIB. The sysORTable is defined as a table listing the capabilities of the local SNMP application acting as a command responder with respect to various MIB modules. However, most SNMP agents do not include the table despite its definition in the SNMPv2-MIB specification. Similarly, an additional way that an NMS can determine the needed MIB modules is to query the SNMP agent and to extract the MIB information from the SNMP agent in various formats, and to reassemble the information locally on the NMS. The problem with this solution is that the numbers of vendors implementing the type of MIB from which the needed information can be extracted are very few. In addition, the MIB access is generally proprietary in nature. An alternative method of determining needed MIBs includes walking an entire SNMP agent's MIB (i.e. using SNMP GetNext requests), to determine the MIB capabilities. However, this method of walking the MIB is slow, network intensive, and prone to be incomplete, as the NMS requires prior knowledge of all needed MIBs in order to correctly cross-reference the SNMP responses with the known Object Identifiers (OIDs) in the NMS.
An SNMP Agent can have several vendors represented in the enterprise area of the MIB. This can be due to partnerships between vendors, a vendor buyout, an OEM deal, etc. One difficult problem has always been to find out which vendors are actually represented in the enterprise area of an SNMP Agent's MIB. Conventional techniques require a review of an MIB support-list (which is standard documentation), from the current agent's vendor in order to understand which MIBs are actually supported by the agent and available to the NMS. If the support-list is unknown, then the common way to date of determining different vendors available in the enterprise area is to perform the type of intensive MIB walk detailed above. This is a less than optimal approach for the reasons discussed above.
A related problem arises once the correct set of MIBs needed for management of an SNMP agent is determined (either through documentation or programmatically). Using conventional methods, the NMS needs to load the MIBs identified as necessary on the NMS in order to manage the SNMP agent. In many cases, it is necessary to locate these MIBs, as they are often proprietary and not readily available. It can take an extended period of time to locate and retrieve these MIBs, and then they must be compiled and/or loaded into the NMS.